《设计模式之禅》 设计模式比较

Veröffentlicht am | Edited on | in . | 次阅读

第三部分 谁的地盘谁做主 – 设计模式比较

一.创建类模式比较

1.工厂方法模式 VS 建造者模式

不同点

  • 意图不同
    工厂方法 注重整体对象的创建方法
    建造者 注重部分构建的过程，详细关注一个产品部件的生产、安装步骤

  • 产品复杂度不同
    工厂方法 对象粒度比较粗
    建造者 对象粒度比较细

2.抽象工厂模式 VS 建造者模式

不同点
抽象工厂
它是从一个更高层次去看对象的构建，具体到工厂内部还有很多的车间，这些都是隐藏在工厂内部的细节，对外不公布，比建造者的尺度要大
建造者
使用在产品的装配方面，如通过装配不同的组件或者相同组件的不同顺序就可以产生一个新的对象

二.结构类模式比较

1.代理模式 VS 装饰模式

共同点是两者具有相同的接口

不同点
代理模式

  • 着重对代理过程的控制
  • 把当前的行为或功能委托给其他对象执行。代理类负责接口限定，是否可以调用真实对象，e.g. AOP

装饰模式

  • 装饰模式是代理模式的一个特殊应用
  • 在保证接口不变的情况下对类的功能进行加强or减弱，不做准入条件判断、准入参数过滤。e.g. java.io.* 包

2.装饰模式 VS 适配器模式

共同点 都是包装作用，通过委托的方式实现其功能

不同点

  • 意图不同
    装饰模式 加强对象的功能，不改变类的行为和属性
    适配器模式 着重转化(伪装)
  • 施与对象不同
    装饰模式 包装的是自己的兄弟类，隶属于同一个家族(相同接口或父类)
    适配器模式 必须是两个(非相同接口)不同的对象
  • 场景不同
    装饰模式 在任何情况下都可以使用
    适配器模式 一个补救模式
  • 扩展性不同
    装饰模式 容易扩展
    适配器模式 一旦建立，后期去掉就比较困难了

    三.行为类模式比较

    1.命令模式 VS 策略模式

    相似点 在命令模式退化时，比如无接收者(接收者非常简单或是一个java的基础操作，无需专门编写一个接收者)，这种情况下，两者的类图完全相同

不同点

  • 关注点不同
    命令模式 着重解耦，通过将请求的内容封装为一个个的命令，来使得请求者和执行者解耦。且同时可以对命令进行多种处理，例如: 撤销、记录
    策略模式 着重算法的完整性、封装性
  • 角色功能不同

    策略模式中的抽象算法和命令模式中的接收者非常相似。不过职责不同

命令模式 关注命令的实现，即功能的实现。接收者的变更只影响到命令族的变更(接收者对命令负责)，对请求者(客户端)没有影响，影响范围仅仅只是抽象命令和具体命令，对它的修改不会扩散到其他模块
策略模式 具体的算法负责一个完整的算法逻辑，是不可拆分的原子业务，当对具体算法进行变更时，就是对算法整体的变更(对客户端可能有影响)

  • 使用场景不同
    命令模式 适用于解耦两个有紧耦合关系的对象场合或者多命令多撤销的场景
    策略模式 适用于算法要求变换的场景

在命令模式中，我们可以把接收者设计得和策略模式的算法相同，也可以不同。在命令模式中，我们按照职责设计的接口就不适用于策略模式(书第一版418)
e.g. zip、gzip压缩 解压缩。接收者可设计成压缩类、解压缩类，也可设计成zip格式类、gzip格式类。在策略模式中，就不能设计成压缩算法类(包含zip、gzip算法)，解压缩算法类(包含zip、gzip算法)，当添加新的格式压缩时会违反开闭原则。所以只能设计成zip格式类(压缩、解压)、gzip格式类(压缩、解压)

2.策略模式 VS 状态模式

不同点

  • 环境角色职责不同
    策略模式 起到一个委托作用，用于算法的替换
    状态模式 不仅仅是委托行为，还具有登记状态变化的功能

  • 解决问题的方式不同
    策略模式 将具体策略类暴露出去，调用者需要具体明白每个策略的不同之处，保证算法可以自由切换
    状态模式 通过内在状态的改变而引起行为改变，状态的改变是由内部条件来改变的

3.责任链模式 VS 观察者模式

DNS解析过程
责任链模式
image-20191219195901007

观察者模式
image-20191219195938936

不同点

  • 链中的消息对象不同
    责任链模式 基本上不会改变消息对象的结构，虽然每个节点都可以参与消费
    观察者模式 在链中传递的对象可以自由变化，只要上下级节点对传递的对象了解即可

  • 上下节点的关系不同
    责任链模式 上下级节点之间没有关系
    观察者模式 上下级关系亲密，下级只关注上级节点的响应，上级只关注下级传递的请求

  • 消息的分销渠道不同
    责任链模式 消息从链首传入后，就沿着链开始运动
    观察者模式 具有很大的灵活性，传递方式可以广播也可跳跃等…

    四.跨战区比较

    1.策略模式 VS 桥梁模式

    附: https://blog.csdn.net/xingjiarong/article/details/50333543

策略模式
image-20191219200016476

桥接模式
image-20191219200203737

不同点

  • 意图不同
    策略模式 将必要信息封装成一个对象就是一个行为
    桥梁模式 解决在不破坏封装的情况下，如何抽取出它的抽象部分和实现部分

  • 变化上
    策略模式 并不考虑Context的变化，只有算法的课替代性。强调Strategy抽象接口的提供是一种算法，一般是无状态，无数据的，Context简单调用这些算法完成其操作
    桥梁模式 Implementor具有变化（ConcreteImplementor），而且Abstraction也可以发生变化（RefinedAbstraction），而且两者的变化是完全独立的，RefinedAbstraction与ConcreateImplementor之间松散耦合

2.门面模式 VS 中介者模式

不同点

  • 功能区别
    门面模式 增加了一个门面，对子系统来说没有增加任何功能。子系统脱离门面可以独立运行
    中介者模式 增加了业务功能，它把各个同事类中的原有耦合关系移植到了中介者，同事类不能脱离中介者而存在

  • 知晓状态不同
    门面模式 子系统不知道有门面存在
    中介者模式 每个同事类都知道中介者的存在，且依靠中介者调和同事之间的关系

  • 封装程度不同
    门面模式 一种简单的封装，所有的请求处理都委托给子系统完成
    中介者模式 一个中心，由中心协调同事类完成，并且中心本身也完成部分业务，中介者属于更进一步的业务功能封装

0%